Method and apparatus providing synchronization and control for server-based multi-screen videoconferencing

ABSTRACT

A videoconferencing system in which multiple browsers are utilized to present content and control functions for a server based videoconference. The content of the videoconference (e.g., video and audio streams) is presented on a display device driven by a local computer running a browser. The local computer also runs a separate browser that presents control functions on a different display device (e.g., a touch screen). The system can be scaled to include additional monitors and browsers running on the local computer. A local server is provided on the local computer for facilitating communications among the locally running browsers. In this manner, the browsers can communicate with each other via the local server executing on the local computer. The need to send traffic to a remote server to effectuate the browser-to-browser communication is eliminated. This provides for reduced latency and lowers the demands on the remote server.

BACKGROUND

Video conferencing among two or more computers has been performed in thepast by connecting separate web browsers running on separate computersto a remote server. Web browsers may be referred to herein as “webapplications” or “browsers.” Examples of common web browsers includeGoogle® Chrome™, Microsoft® Internet Explorer®, Mozilla® Firefox®,Apple® Safari®, among others. Once connections are established betweenthe various web browsers and the remote server, content and controlinformation may be provided from the server to the various browsersrunning on the various computers. For example, the server may receivestreaming content from each browser, processes the streaming content,and make the content available back to the browsers in a formattedmanner. The remote server controls the information that is received andmade available to the browsers on an individual basis. If a browserseeks to change a format or otherwise provide modified controlinformation, such control information is transmitted to and processed bythe remote server. Depending on the processing, the remote server mightmodify content, format or control information made available to all orsome of the browsers. In this manner, functionality of the browserssupporting the videoconference requires communication and processing bythe remote server.

In instances where the server operates to provide control and contentinformation to the browsers, latency is incurred as information isprocessed from one browser and made available to the others. Forexample, such information might move through several stages ofprocessing and transmission: the information may be initially processedby a browser for transmission to the server, the information may betransmitted through the web, the information may be received andprocessed by the server, action may be taken and the result may be madeavailable to any other appropriate browsers connected to the server. Theserver in such instance carries a substantial portion of the processingload.

Such deficiencies discourage the use of multiple browsers at a singlelocation. If it were attempted, latency would be expected and additionalloads would be placed on the server among other things. Even if twobrowsers were open in a single browser application loaded on a singlemachine, they would still be expected to coordinate through the serverthereby incurring the undesirable latency, server burden and otherproblems.

When two separate browser instances wish to communicate information(i.e., two separate browser windows open on the same machine), aconventional technique involves use of a “hanging get” or the like tofacilitate communications. When a first browser communicates a messageto a second browser, the local machine on which the two browsers arerunning makes a request over the Internet to a remote server to open acommunication channel between the local machine and the remote server.When the remote server receives the request, the remote server leaves acommunication link between the remote server and the local machine thatis executing the two browsers. The local machine is able to sendinformation to the remote server when needed. After processing, theserver can then make the information available to the second browser. Inthis manner, hanging gets allow the remote server to push notificationsto the local machine without the local machine having to poll forupdates. Also, when a first browser wants to send a message to anotherbrowser, the first browser may post a message to the remote server overHTTP via the communication channel. In response, the remote server maywrite the message back to the other connected browser(s) over theestablished “hanging get” communication channel to complete thenotification from the first browser to the second browser.

Hanging gets provide an expensive implementation, from the server'sstandpoint, because the server has to keep this a hanging getcommunication channel open until the local machine is disconnected. Thislimits the number of simultaneous connections the server can handle,which means the service being provided does not scale well. There isalso a latency problem with hanging gets because messages aretransmitted from the client to the remote server and then back. Inaddition, a discovery problem exists since the server needs to knowwhich browser should receive the message when the server sends themessage back to the client via the communication channel.

Accordingly, there remains a need for a method and apparatus providingsynchronization and control for server-based multi-screenvideoconferencing. There further remains a need for a method andapparatus allowing two browsers to communicate while addressing thedrawbacks and limitations discussed above.

SUMMARY

In some instances, a video conferencing system apparatus is providedwhich includes a content display device coupled to a local computer anddisplaying streaming images provided by a remote server, the streamingimages being displayed by a first browser executing on the localcomputer and communicatively coupled to the remote server; a controldisplay device coupled to the local computer and displaying a controlinterface, the control interface being displayed by a second browserexecuting on the local computer, such second browser receiving commandsthrough the control interface of the control display device; and a localcommunication server executing on the local computer and communicativelycoupled to the first browser and the second browser, the localcommunication server receiving such a command from the second browserand transmitting such command to the first browser displaying thestreaming images so that the command is capable of being executed by thefirst browser independently of communications with the remote server.

In other instances, a method and non-transitory computer-readablestorage medium for updating one or more browsers executing on a computersystem are provided for receiving an update from a first browserexecuting on the computer system at a local communication serverexecuting on the computer system; identifying, with the localcommunication server, one or more other browsers executing on thecomputer system that should receive such update, wherein at least one ofthe one or more other browsers displays an image received from a remoteserver external to the computer system; and transmitting from the localcommunication server such update to the one or more other browserswithout requiring the remote server to receive and retransmit suchupdate.

In still other instances, a system for updating one or more browsersexecuting on a computer is provided which includes a remote server and alocal computer device coupled to the remote server and executing one ormore browsers. The computer device further executes a localcommunication server configured to: receive an update from a firstbrowser executing on the local computer device at the localcommunication server; identify, with the local communication server, oneor more other browsers executing on the local computer device thatshould receive such update, wherein at least one of the one or moreother browsers displays an image received from the remote server; andtransmit from the local communication server such update to the one ormore other browsers without requiring the remote server to receive andretransmit such update.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example video conferencing apparatus includingmultiple screens;

FIG. 2 is a block diagram of an example data delivery environment,according to one embodiment.

FIG. 3 is a block diagram of example functional components for one ofthe client devices in FIG. 2, according to one embodiment.

FIG. 4 is a conceptual diagram illustrating a system for providingcommunications sessions, according to one embodiment.

FIG. 5 is a conceptual diagram illustrating a display browser in amulti-browser system, according to one embodiment.

FIG. 6 is a conceptual diagram illustrating a control browser in amulti-browser system, according to one embodiment.

FIG. 7 is a conceptual diagram illustrating communication between twoweb browsers via local server, according to one embodiment.

FIG. 8 is a flowchart illustrating initializing a two-browsercommunication session platform, according to one embodiment.

FIG. 9 is a flowchart illustrating communication between two webbrowsers via local server, according to one embodiment.

DETAILED DESCRIPTION OF EXAMPLES

Face-to-face or in-person interactions among groups of individuals alloweach individual to observe the behavior, mood, expressions, tone, andthe like of the other individuals in the group. Group interactions canfacilitate relationship building by creating shared experiences.Traditionally, such group interactions were restricted to in-personcongregations of the group. With all of the individuals together, theyare able to share experiences like mutually participating in interactivesessions or audio/visual presentations. The camaraderie can besubstantial and long-lasting.

More recently, face-to-face group meetings among participants at remotelocations have been permitted with live video and audio feeds of each ofthe participants. Each of personal computers (PCs), personal digitalassistants (PDAs), and mobile phones with advanced computingcapabilities (i.e., “smartphones”) are now commonly equipped with bothmicrophones and video cameras that provide the basic resources forcreating a shared session among a group of individuals.

Such shared sessions rely on Internet-based communication protocols suchas “Voice over IP” (VoIP). Streams of video and audio packets arecreated, transmitted across the Internet, and decoded and reassembled ina manner permitting each recipient to hear and see the otherparticipants in a face-to-face manner.

The shared sessions can be presented to a user via stand-aloneconferencing applications executing on the user's device or via one ormore browser applications. In some embodiments, when the shared sessionsare presented to the user via a browser application. In one example of atwo-browser shared session, a first browser may present the audio andvideo content of the shared session (i.e., acting as a “displaybrowser”) and the second browser may be a “control browser” forcontrolling various aspects of the shared session, e.g., volume, mute,video zoom in/out, etc. In other embodiments, any number of displaybrowsers and any number of control browsers may be presented to users atthe same location.

Embodiments of the detailed description provide an apparatus and methodby which two or more browsers can communicate with one another. Anexample application includes implementation to facilitate amulti-browser shared session. According to various embodiments, a localserver is executing on the same machine as the two or more browsers andis configured to communicate with the two or more web browsers. In oneexample, the local server comprises a WebSocket server though othermessaging protocols besides WebSocket can also be used to implement thelocal server. When a first browser wishes to communicate with a secondbrowser, the first browser sends a message to the local server. Thelocal server then transmits a copy of the message to the second browserand/or to any additional browsers that should receive the message. Inthis manner, the browsers can communicate with one another without theneed to transmit messages to and from a remote server, as is requiredwith the “hanging get” protocol.

An example multi-screen videoconferencing system is depicted in FIG. 1.The depicted system includes two multi-screen conferencing locations,but there could be more. FIG. 1 specifically depicts a first localconferencing location 10 and a second local conference location 15. Asdepicted, these could be conference rooms. In the example of FIG. 1, theconference location 10 includes a large screen monitor 20 and a smallmonitor 30. Conference location 15 includes a large screen monitor 25and a small monitor 35. The small monitors 30 and 35 can be comprised ofany single or multiple combinations of monitor and input devices. Asdepicted, touch screen monitors 30 and 35 are provided with a connectionto a computer 40 or 45 through communication lines 32 and 37,respectively, e.g, a USB connection. The large monitors 20 and 25 aresimilarly connected to the computers 40 and 45 through communicationlines 22 and 27, respectively, e.g., a coax, RGB cable, VGA, etc. Thecomputers 40 and 45 are also connected through communication links 42and 47, respectively, to a remote server 50, through a network web 60,such as the world wide web, an extended network, a VPN, or the like.

The computers 40 and 45 are provided with multiple independent browsers(including separate browser applications and browser pages, etc.)executing. First browsers running on the computers 40 and 45 areconfigured to display on the large screen monitors 20 and 25, and secondbrowsers are configured to display on the small monitors 30 and 35.Content is provided by the server 50 and displayed by the first browserson the large screen monitors 20 and 25. The content may be formatted toreflect certain control functions and status displays. The firstbrowsers can also be connected directly or indirectly to a soundmicrophone and video camera, or a combination thereof. Sound and videocontent is provided by the first browser to through the network 60 tothe remote server 50.

Second browsers receive control information and display it upon smallmonitors 30 and 35. The second browsers also receive control informationfrom the second monitors 30 and 35. In some instances, the controlinformation relates to activities occurring on the first browser, as forexample the receipt and establishment of content. When a user inputs achange in connection with the small control monitor 30 or 35, the secondbrowser adjusts the control screen and transmits the control change tothe server 50. The second browser also communicates the control changeto a local server which is in connection with the first browser. In thismanner, the second browser can update the first browser without relianceon the remote server 50. The remote server 50 is still updated, but moreto update the remote browsers rather than the local browser where thechange occurred. In one embodiment, the first browsers and the secondbrowsers comprise separately executing instances of two or more browserapplications. In another embodiment, the first browsers and the secondbrowsers comprise browser tabs within a single executing browserinstance.

FIGS. 2-3 depict an example data delivery environment that might beimplemented to support the video conferencing system depicted in FIG. 1.The illustrated environment is presented as an example, and does notimply any limitation regarding the use of other data deliveryenvironments. To the contrary, the description contemplates allimplementations of data delivery environments that have the capabilityto communicate between two browser instances.

As shown in FIG. 2, the data delivery environment includes server(s) 300in communication with one or more client devices 100A-100D. Examples ofclient devices 100A-100D include, but are not limited to, portable,mobile, and/or stationary devices such as landline telephones, mobiletelephones (including “smartphones”), laptop computers, tabletcomputers, desktop computers, personal digital assistants (PDAs),portable gaming devices, portable media players, e-book readers,Internet-enabled televisions, or Internet-enabled appliances, amongothers. In some embodiments, two or more client devices 100A-100D arethe same type of device. For example, client devices 100A and 100B mayboth be desktop computers. In other embodiments, two or more clientdevices are different types of devices. For example, client devices 100Aand 100B may both be desktop computers and client device 100C may be asmartphone.

In the embodiment illustrated by FIG. 2, the client devices 100A-100Dcommunicate with a server(s) 300 via communications channels 200A-200D,respectively. In one embodiment, the communications channels 200A-200Dinclude an Internet connection between the client devices 100A-100D andthe server(s) 300. In other embodiments, the connection may be overcellular phone network or other type of network. The server(s) 300 oftencomprise multiple physical servers such as a communications server 320for maintaining or “hosting” one or more communication sessions 340.According to various embodiments, each server can be a physicallyseparate machine or can be different processes running within the samephysical machine.

The client device 100A of FIG. 2 includes application(s) 120,communications client 140, output devices 160 (e.g., a display), andinput devices 180 (e.g., keyboard, mouse, touch screen). In someembodiments, a device may act as both an output device and an inputdevice. An example of web application(s) 120 is a web browserapplication. Web application(s) 120 provide the client device 100A witha variety of functionalities. Examples include social mediafunctionality, web browsing capabilities, calendars, contactinformation, games, and document processing, document sharing, amongothers. Web application(s) 120 employ the output devices 160 to displayinformation at a graphical user interface (GUI).

The communications client 140 further includes a communications module145 that enables output devices 160 to display information at the GUI.The communications module 145 also enables the communications client 140to connect to the server(s) 300. Typically, the communications module145 is a network module that connects the client device 100A to anetwork, such as the Internet or a cellular phone network, using one ofa variety of available network protocol techniques. The GUI isconfigured to display data (such as, for example, audio and video data)received from the server(s) 300 over the communications channel 200A.

As also shown, client device 100A includes a local server 165. In someembodiments, the local server 165 comprises a WebSocket server. Asdescribed in greater detail herein, the local server 165 provides amechanism for two separate browser instances running on the clientdevice 100A to communicate with one another without the need forcommunicating with remote server(s) 300.

In some embodiments, client devices 100B-100D include similar elementsand functions as client device 100A. In other embodiments, clientdevices 100B-100D include different, fewer, or more elements andfunctions as client device 100A.

Referring now to FIG. 3, one particular example of client device 100A isillustrated. Many other embodiments of the client device 100A may beused. In the illustrated embodiment of FIG. 3, the client device 100Aincludes one or more processors 101, memory 102, a network interface103, one or more storage devices 104, a power source 105, outputdevice(s) 160, and input device(s) 180. The client device 100A alsoincludes an operating system 108, a communications client 140, and alocal server 165 that are executable by the client. Each of components101, 102, 103, 104, 105, 160, 180, 108, 140, and 165 are interconnectedphysically, communicatively, and/or operatively for inter-componentcommunications in any operative manner.

As illustrated, processors 101 are configured to implement functionalityand/or process instructions for execution within client device 100. Forexample, processors 101 execute instructions stored in memory 102 orinstructions stored on storage devices 104. Memory 102, which may be anon-transient, computer-readable storage medium, is configured to storeinformation within client device 100 during operation. In someembodiments, memory 102 includes a temporary memory, area forinformation not to be maintained when the client device 100 is turnedOFF. Examples of such temporary memory include volatile memories such asrandom access memories (RAM), dynamic random access memories (DRAM), andstatic random access memories (SRAM). Memory 102 maintains programinstructions for execution by the processors 101.

Storage devices 104 also include one or more non-transientcomputer-readable storage media. Storage devices 104 are generallyconfigured to store larger amounts of information than memory 102.Storage devices 104 may further be configured for long-term storage ofinformation. In some examples, storage devices 104 include non-volatilestorage elements. Non-limiting examples of non-volatile storage elementsinclude magnetic hard discs, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) orelectrically erasable and programmable (EEPROM) memories.

The client device 100A uses network interface 103 to communicate withexternal devices via one or more networks, such as one or more wirelessnetworks. Network interface 103 may be a network interface card, such asan Ethernet card, an optical transceiver, a radio frequency transceiver,or any other type of device that can send and receive information. Othernon-limiting examples of network interfaces include Bluetooth®, 3G andWiFi® radios in mobile computing devices, and USB (Universal SerialBus). In some embodiments, the client device 100A uses network interface103 to wirelessly communicate with an external device such as theserver(s) 300 of FIG. 2, a mobile phone, or other networked computingdevice.

The client device 100A includes one or more input devices 180. Inputdevice 180 is configured to receive input from a user through tactile,audio, and/or video feedback. Non-limiting examples of input device 180include a presence-sensitive screen, a mouse, a keyboard, a voiceresponsive system, a video camera, a microphone, or any other type ofdevice for detecting a command from a user. In some examples, apresence-sensitive screen includes a touch-sensitive screen.

One or more output devices 160 are also included in client device 100A.Output device 160 is configured to provide output to a user usingtactile, audio, and/or video stimuli. Output device 160 may include adisplay screen (part of the presence-sensitive screen), a sound card, avideo graphics adapter card, or any other type of device for convertinga signal into an appropriate form understandable to humans or machines.Additional examples of output device 160 include a speaker, a cathoderay tube (CRT) monitor, a liquid crystal display (LCD), or any othertype of device that can generate intelligible output to a user. In someembodiments, a device may act as both an input device and an outputdevice.

The client device 100A includes one or more power sources 105 to providepower to the client device. Non-limiting examples of power source 105include single-use power sources, rechargeable power sources, and/orpower sources developed from nickel-cadmium, lithium-ion, or othersuitable material.

The client device 100A includes an operating system 108, such as theAndroid® operating system. The operating system 108 controls operationsof the components of the client device 100A. For example, the operatingsystem 108 facilitates the interaction of communications client 140 andlocal server 165 with processors 101, memory 102, network interface 103,storage device(s) 104, input device 180, output device 160, and powersource 105.

As illustrated in FIG. 3, the client device 100A includes communicationsclient 140 and local server 165. Communications client 140 includescommunications module 145. Each of communications client 140,communications module 145, and local server 165 includes programinstructions and/or data that are executable by the client device 100A.For example, in one embodiment, communications module 145 and/or localserver 165 includes instructions causing the communications client 140and/or local server 165 executing on the client device 100A to performone or more of the operations and actions described in the presentdisclosure. In some embodiments, communications client 140 and/orcommunications module 145 and/or local server 165 form a part ofoperating system 108 executing on the client device 100A.

FIG. 4 is a conceptual diagram illustrating a system 301 for providingcommunications sessions, according to one embodiment. As shown, system301 includes client devices 302A, 302B, a connection server 304, a roomserver 306, and a reflector 308. In one embodiment, client devices 302A,302B may be similar to or the same as client devices 100A-100D shown inFIG. 2. As shown in the simplified diagram in FIG. 4, the client devices300A, 300B include a communications client 140, browsers 202, 204, and alocal server 165.

The system 301 provides a mechanism for two or more users to interact inthe same virtual location, which may be described as a communicationsession. The communication session may be, for example, a videoconferencing session. A communication session supports multiple users,using diverse communication tools, to interact, collaborate, and/orshare information and experiences in the same virtual environment. In anInternet environment, the communication session is hosted by one or moreservers that support communications sessions with user machines equippedwith resources such as microphones and video cameras. For example,individuals participating in a communication session may share and watchvideos, play games, participate in video, audio, or text chat, surf theweb, seek or provide assistance regarding a particular problem, or anycombination thereof. In other words, a communication session is whereindividuals may share an experience substantially similar to interactingin person at the same physical location.

When an individual desires to interact with a group of others in avirtual environment, the individual employs a client device, such asclient device 302A, to either initiate a communication session or joinan existing communication session. When establishing a new communicationsession, the individual may invite others to join the session.

In one embodiment, to join an existing communication session, eachparticipant is invited. Invitations may be delivered in many differentmanners including via e-mail or text messaging services. A user canrequest joining an existing communication session even though the userhas not received an invitation, assuming the URL for the session isknown. Additionally, users participating in a communication session maycause the session to link to external resources and integrate thoseexternal resources into the participant's graphical user interface(GUI).

In other embodiments, each communications session is associated with a“session name.” The session name may be an alpha-numeric string ofcharacters that uniquely defines the communication session. To join acommunication session, in some embodiments, the user may enter thesession name into a control browser, as described herein. Somecommunication sessions may also be password protected.

An example of user workflow for joining a communication session isprovided below. The user enters a session name into a browser 202configured to the accept session names. In one example, browser 202 is acontrol browser and browser 204 is a display browser, as describedabove. Browser 202 is configured to communicate with communicationsclient 140 installed on the client device 302A. The communicationsclient 140 is configured to communicate with connection server 304. Inother embodiments, the browsers 202, 204 are configured to directlycommunicate with the connection server 304. In one embodiment, thecommunication between the communications client 140 and/or browsers 202,204 and connection server 304 is over the HTTP protocol (HypertextTransfer Protocol), though it could be others available for similarfunctionality. The communications client 140 and/or browsers 202, 204are configured to transmit a message to the connection server 304 thatincludes the session name entered by the user.

The connection server 304 receives the message that includes the sessionname. The connection server 304 is configured to translate the sessionname to a unique and deterministic identifier for the communicationsession that the user desires to join. In one example, the deterministicidentifier is a Jabber Identifier (JID) or similar network connectionidentifier providing similar functionality. In the embodiment utilizingJID, communicated information may include a node identifier, a domainidentifier, and a resource identifier.

The connection server 304 is configured to interact with a room server306 that is configured to manage the virtual “rooms” for the variouscommunications sessions. The connection server 304 is configured totransmit the deterministic identifier to the room server 306 and/or theclient device 300A.

Based upon such information, the room server 306 determines whether acommunications session having the deterministic identifier has alreadybeen created. If not, then the room server 306 creates a new virtualroom for the new communications session.

A reflector 308 is in communication with the room server 306 and managesthe virtual rooms of the communications sessions. The reflector 308 isconfigured to interact with client devices 300A, 300B to provide thevideo and audio content of the communication session to the variousclient devices. In one example, the communication between the reflector308 and the client devices 300A, 300B is via a TCP (Transmission ControlProtocol) or UDP (User Datagram Protocol) connection, though it mayinclude any protocol with similar functionality.

Each deterministic identifier corresponds to a particular reflector 308associated with the communication session and is used by the connectionserver 304 to establish a connection between the client devices 300A,300B and the particular reflector 308. The one or more client devices300A, 300B are configured to send audio and video content to thereflector 308.

The reflector 308 receives content from several separate client devices300A, 300B and buffers all incoming packets before synchronizing themand reordering them into various data sessions corresponding to eachdevice connected to a communication session. In the example embodiment,these data sessions (or “real-time” sessions) are RTP sessions thatinclude multiple RTP streams, thought any similar functioning protocolscould be implemented. For example, an RTP session provided by thereflector 308 corresponding to a particular client device includes allcontent received at the reflector except for the content received fromthat particular client device. Thus, the reflector 308 would provide anRTP session to that particular client device including RTP streamsreceived at the reflector from all other client devices in thecommunication session.

In one embodiment, each of the communications server 304, room server306, and reflector 308 is included in server(s) 300 shown in FIG. 2.FIG. 4 only depicts a particular reflector 308 corresponding to aparticular communication session, but it will be appreciated that aplurality of reflectors may reside in the system 301. While FIG. 4depicts all these modules as being a part of server(s) 300, it will beappreciated that the implementation of these modules may be spreadacross different tangible servers and that certain modules may be aseparate component in communication with the modules of the server(s)300. It will further be appreciated that certain modules can be combinedinto a single module, for example, the communications server 304 androom server 306 may be combined into a more comprehensive module. Inother embodiments, the various components may be integrated into asingle platform while maintaining their individual functionality andidentity, such platform may be a single server or distributedapplication.

As described and as shown in FIG. 4, in some embodiments, the clientdevice 300A may include multiple browsers. One browser may comprise adisplay browser for displaying the video and audio content of thecommunication session and another browser may comprise a control browserfor controlling various aspects of the communication session.

FIG. 5 is a conceptual diagram illustrating a display browser 502 in amulti-browser system, according to one embodiment. The display browser502 may be presented to the user on a display device 500 coupled to theclient device. For example, the display device 500 may be an LCD orplasma display. The display browser 502 may be presented on the displaydevice 500 in “full-screen” mode. In such a case, the user may not evenbe aware that the display device 500 is presenting a web browser on thedisplay device 500.

A client application, such as communications client 140, supportscommunication session functionality. The client application exposes anumber of features to the user through a GUI. These graphicallydisplayed features include a video display 504 of one or moreparticipants in the communication session. A chat log 506 is alsoprovided, including a chat history and a field 508 where a user caninput text to the chat conversation. The display browser 502 is alsoconfigured to display graphical images 510 that are associated withparticipants in the communication session. Graphical images 510 includeimages of users currently participating in the communication session.

FIG. 6 is a conceptual diagram illustrating a control browser 602 in amulti-browser system, according to one embodiment. The control browser602 may be presented to the user on a display device 600 coupled to theclient device. For example, the display device 600 may be atouch-sensitive display device for receiving input. The control browser602 may be presented on the display device 600 in “full-screen” mode. Insuch a case, the user may not even be aware that the display device 600is presenting a web browser on the display device 600.

As described, the control browser 602 provides an interface for a userto control various aspects of the communication session. The controlbrowser 602 may also present identifying information 608 about the userand the communication session, such as the user's name, a name of thecommunication session, a total number of participants in thecommunication session, a physical location of the user. The controlbrowser 602 may also provide one or more interface buttons 604 by whicha user can control various aspects of the communication session.Examples of interface buttons 604 include buttons to mute a user's audiofeed, mute/blackout a user's video feed, remote mute another user,increase/decrease audio volume, zoom video in/out, among others. An exitbutton 606 may also be provided for the user to exit the communicationsession.

In operation, a user may select one of the interface buttons 604 tocontrol certain aspects of the communication session. For example, theuser may desire to mute himself or herself. The user would select theappropriate interface button 604. In response to the selection of aninterface button 604, the control browser 602 transmits a message to thelocal server 165 executing on the client device that is coupled to thedisplay device 600 and executes the control browser 602. The localserver 165 receives the message and transmits the message to the displaybrowser 502 shown in FIG. 5. The display browser 502 is also executingon the same client device as the local server 165.

The display browser 502 receive the message and takes appropriate actionin response to the message. For example, if the message is related tothe mute function, the display browser 502 disables the microphone thatthe user is speaking into. Also, the display browser 502 may display anicon indicating that the user is muted. In addition, the display browser502 sends a message to the connection server 304 corresponding to thedesired action. The messages may be sent via the HTTP protocol or anyother protocol with similar functionality.

The connection server 304 receives the message from the first browserexecuting on a client device and transmits a corresponding message tothe other client devices participating in the communication session. Theother client devices also take appropriate action, including, forexample, displaying an icon next to the user indicating that the user ismuted.

FIG. 7 is a conceptual diagram illustrating communication between twoweb browsers via local server, according to one embodiment. As shown, aclient device 700 is executing a display browser 704, a control browser706, and a local server 702. The display browser 704 and the controlbrowser 706 are each configured to communicate with the local server702. In one example, the local server 702 may be a WebSocket server.Also, each of the display browser 704 and the control browser 706 iscoupled to the connection server 304 via an HTTP connection.

When a user 710 wishes to change some aspect of a communication session,the user makes an input via the control browser 706. The control browser706 sends a message to the local server 702, which then sends a messageto the display browser 704. The display browser 704 then takesappropriate action in response to the message. The display browser 704also sends a message to the connection server 304 to relay the messageto the other client devices participating in the communication session.In this manner, communications sent between the control browser 706 andthe display browser 704 pass through the local server 702, which isexecuting on the same client device 700 as the control browser 706 andthe display browser 704. Therefore, the communication sent between thecontrol browser 706 and the display browser 704 does not need to be sentto any remote servers outside the client device 700, such as theconnection server 304.

FIG. 8 is a flowchart illustrating initializing a two-browsercommunication session platform, according to one embodiment. Personsskilled in the art will understand that even though the method 800 isdescribed in conjunction with the systems of FIGS. 1-7, any systemconfigured to perform the method stages is within the scope ofembodiments of the disclosure.

As shown, at stage 802, a client device powers ON and boots an operatingsystem (OS). At stage 804, a local server starts running on the clientdevice. In some embodiments, an “autorun” feature may be enabled on theclient device that causes the local server to start running once theclient device is powered ON and the OS is booted. In one embodiment, thelocal server is a WebSocket server. In other embodiments, the localserver may be server configured with a different messaging protocoldifferent from WebSocket.

At stage 806, a communication application begins executing. In someembodiments, an “autorun” feature may be enabled on the client devicethat causes the communication application to start executing once theclient device is powered ON and the OS is booted. In some embodiments,the communication application comprises the communications client 140described herein. In some embodiments, the communication application isconfigured to detect the hardware devices coupled the client device. Forexample, the communication application may determine the type and numberof the display devices and input devices coupled to the client device.One technique may involve the communication application analyzing theserial numbers of the hardware devices coupled to the client device andidentifying the devices based on their serial numbers. Depending on thecount and number of different hardware devices coupled to the clientdevice, the communication application may determine the number of“display browsers” and the number of “control browsers” that should beincluded in the communication environment provided by the client device.In the examples included herein, one display browser and one controlbrowser are discussed. However, in alternative embodiments, two or moredisplay browsers and/or two or more control browsers may be implemented.Each of the two or more display browsers may present the same or adifferent interface. Similarly, each of the two or more control browsersmay present the same or a different interface.

Continuing with the example of one display browser and one controlbrowser, at stage 808, the communication application opens a firstbrowser window and a second browser window. The first browser window maybe opened on a first display device coupled to the client device. In oneembodiment, the first browser window comprises a “display browser,” asdescribed herein. The second browser window may be opened on a seconddisplay device coupled to the client device. In one embodiment, thesecond browser window comprises a “control browser,” as describedherein.

At stage 810, each of the first and second browser windows downloads aJavaScript from remote server. The remote server may comprise one ormore of the connection server 304, room server 306, and reflector 308described above in FIG. 4. The JavaScript includes instructions forpresenting a communication session to a user. The JavaScript may beperiodically updated on the remote server. When the browser downloadsthe JavaScript from the remote server, the browser retrieves the latestversion of the JavaScript. In other embodiments, instructions forpresenting the communication session are downloaded from the remoteserver in a format other than JavaScript.

At stage 812, each of first and second browser windows establishes aconnection with the remote server. In one embodiment, the connectionbetween each browser and the remote server is over HTTP. For example,the connection may implement the “hanging get” protocol.

At stage 814, each of first and second browser windows establishes aconnection with the local server. In one embodiment, the connectionbetween each browser and the remote server is over the WebSocketprotocol. A user may then create or join a communication session byentering a session name into the control browser in the appropriatefield of a control broswer. The control browser communicates thisinformation to the display browser (i.e., for display) and to the remoteserver, as described in FIG. 4.

Once the user has established a connection with a particularcommunication session and the communication session is in progress, theuser may wish to alter some aspect of the communication session. Asdescribed, the user may enter appropriate inputs into the controlbrowser. The inputs are then conveyed to the display browser and to theclient devices of the other users participating in the communicationsession.

FIG. 9 is a flowchart illustrating communication between two webbrowsers via local server, according to one embodiment. Persons skilledin the art will understand that even though the method 900 is describedin conjunction with the systems of FIGS. 1-7, any system configured toperform the method stages is within the scope of embodiments of thedisclosure.

As shown, at stage 902, a local server receives a request from each of afirst browser and a second browser to connect to the local server. Asdescribed above, the local server is executing on the same client deviceas first browser (e.g., “display browser”) and second browser (e.g.,“control browser”).

At stage 904, the local server establishes a connection with the firstbrowser and a connection with the second browser. As described, theconnections may be WebSocket connections.

At stage 906, the local server receives a message from a second browser.In one embodiment, the message may relate to changing an aspect of acommunication session. Additionally, any message that is to becommunicated between two browsers is within the scope of embodiments ofthe disclosure.

At stage 908, the local server transmits the message to the firstbrowser. The message is transmitted to the first browser via theconnection (e.g., WebSocket connection) between the local server and thefirst browser.

In this manner, the first and second web browsers can communicate withone another without accessing a remote server. This feature isaccomplished via a local server, such as a WebSocket server, executingon the same client device. More efficient operation is thereby achieved.

In the example embodiments, the various applications can be configuredon any distributed or embedded platform within a single physicallocation or multiple locations. As such, embodiments contemplate thatapplications, resources, managers, servers, etc. may be joined orseparated without diverging from their identities and functions. Forexample, a “server device” may include a single server platform ormultiple server platforms.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedto be incorporated by reference and were set forth in its entiretyherein.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosure (especially in the context of thefollowing claims) are to be construed to cover both the singular and theplural, unless otherwise indicated herein or clearly contradicted bycontext. The terms “comprising,” “having,” “including,” and “containing”are to be construed as open-ended terms (i.e., meaning “including, butnot limited to,”) unless otherwise noted. Recitation of ranges of valuesherein are merely intended to serve as a shorthand method of referringindividually to each separate value falling within the range, unlessotherwise indicated herein, and each separate value is incorporated intothe specification as if it were individually recited herein. All methodsdescribed herein can be performed in any suitable order unless otherwiseindicated herein or otherwise clearly contradicted by context. The useof any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate the disclosureand does not pose a limitation on the scope of the disclosure unlessotherwise claimed. No language in the specification should be construedas indicating any non-claimed element as essential to the practice ofthe disclosure.

One embodiment of the disclosure may be implemented as a program productfor use with a computer system. The program(s) of the program productdefine functions of the embodiments (including the methods describedherein) and can be contained on a variety of computer-readable storagemedia. Illustrative computer-readable storage media include, but are notlimited to: (i) non-writable storage media (e.g., read-only memorydevices within a computer such as CD-ROM disks readable by a CD-ROMdrive, flash memory, ROM chips or any type of solid-state non-volatilesemiconductor memory) on which information is permanently stored; and(ii) writable storage media (e.g., floppy disks within a diskette driveor hard-disk drive or any type of solid-state random-accesssemiconductor memory) on which alterable information is stored.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the disclosure.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate, and the inventors intend for the disclosure to be practicedotherwise than as specifically described herein. Accordingly, thisdisclosure includes all modifications and equivalents of the subjectmatter recited in the claims appended hereto as permitted by applicablelaw. Moreover, any combination of the above-described elements in allpossible variations thereof is encompassed by the disclosure unlessotherwise indicated herein or otherwise clearly contradicted by context.

The invention claimed is:
 1. A video conferencing system, comprising: acontent display device coupled to a local computer and displayingstreaming images provided by a remote server during a communicationsession, the streaming images being displayed by a first web browserexecuting on the local computer and communicatively coupled to theremote server; a control display device coupled to the local computerand displaying a control interface, the control interface beingdisplayed by a second web browser executing on the local computer, suchsecond web browser receiving a command through the control interface ofthe control display device for controlling presentation of the streamingimages provided by the remote server during the communication session;and, a local communication server executing on the local computer andcommunicatively coupled to the first web browser and the second webbrowser, the local communication server receiving such command from thesecond web browser and transmitting such command to the first webbrowser displaying the streaming images so that the command is receivedby the first web browser independently of communications with the remoteserver and the received command is communicated by the first web browserto the remote server.
 2. The video conferencing system according toclaim 1, wherein the control display device includes a touch-sensitivesurface, and the control interface is displayed on the touch-sensitivesurface.
 3. The video conferencing system according to claim 1, whereinthe streaming images provided by the remote server also include audioassociated therewith.
 4. The video conferencing system according toclaim 1, wherein the local communication server comprises a WebSocketserver and the commands received by the WebSocket server from the firstbrowser and the commands transmitted by the WebSocket server to thesecond browser comprise WebSocket commands.
 5. The video conferencingsystem according to claim 1, wherein the first browser displayed by thecontent display device and the second browser displayed by the controldisplay device are displayed in full screen mode.
 6. A method forupdating one or more browsers executing on a computer system, the methodcomprising: receiving an update during a communication session from afirst web browser executing on the computer system at a localcommunication server executing on the computer system; identifying, withthe local communication server, one or more other web browsers executingon the computer system that should receive such update, wherein at leastone of the one or more other web browsers is configured to presentstreaming image data received from a remote server external to thecomputer system during the communication session, and the update isassociated with changing how the data received from the remote serverexternal to the computer system is presented; transmitting from thelocal communication server such update to the one or more other webbrowsers without requiring the remote server to receive and retransmitsuch update; and transmitting the update to the remote server by atleast one of the one or more other web browsers that is configured topresent streaming image data.
 7. The method according to claim 6,wherein the update corresponds to a command received by the firstbrowser.
 8. The method according to claim 6, wherein the image receivedfrom the remote server corresponds to a video conference session.
 9. Themethod according to claim 6, further comprising: determining a number ofdisplay devices coupled to the computer system; identifying at least oneof the display devices to be a content display device; identifying atleast one of the display devices to be a control display device.
 10. Themethod according to claim 9, further comprising: for each display devicecoupled to the computer system, determining a serial number of thedisplay device; and identifying the at least one content display deviceand the at least one control display device based on the serial numbersof the display devices.
 11. The method according to claim 10, whereinthe local communication server comprises a WebSocket server.
 12. Asystem for updating one or more web browsers executing on a computer,such system comprising: a remote server; and a local computer devicecoupled to the remote server and executing two or more web browsers,wherein the computer device further executes a local communicationserver configured to: receive an update from a first web browser of thetwo or more web browsers executing on the local computer device at thelocal communication server during a communication session; identify,with the local communication server, one or more other web browsersexecuting on the local computer device that should receive such update,wherein at least one of the one or more other web browsers is configuredto present data received from the remote server during the communicationsession, and the update is associated with changing how the datareceived from the remote server is presented; transmit from the localcommunication server such update to the one or more other web browserswithout requiring the remote server to receive and retransmit suchupdate; and transmit the update to the remote server with at least oneof the one or more other web browsers that is configured to present datafrom the remote server.
 13. The system according to claim 12, whereinthe local communication server comprises a WebSocket server and theupdate received by the WebSocket server from the first browser and theupdate transmitted by the WebSocket server to the at least one of theone or more other browsers comprise WebSocket commands.
 14. The systemaccording to claim 12, wherein at least one of the one or more otherbrowsers is configured to display an image received from the remoteserver corresponding to a video conference session.
 15. The systemaccording to claim 14, wherein the update corresponds to a remote mutecommand.
 16. The system according to claim 14, wherein the image isreceived from the remote server via a TCP (Transmission ControlProtocol) packet or UDP (User Datagram Protocol) packet.
 17. The systemaccording to claim 14, wherein the first browser and the at least one ofthe one or more other browsers are each coupled to the remote server viaan HTTP (Hypertext Transfer Protocol) connection.
 18. The systemaccording to claim 12, wherein the first browser is configured todownload a script from the remote server, wherein the update istransmitted from the first browser to local communication server whenthe first browser executes the script.
 19. The system according to claim12, wherein each of the one or more browsers comprises a separatebrowser window executing within a separate execution environment on thelocal computer device.
 20. The video conferencing system according toclaim 1, wherein the first browser and the second browser comprise twobrowser tabs within a single browser instance.